Relational Database Systems, such as SQL Server™ available from Microsoft® in Redmond Wash., allow users to index data in various ways. Indexes can speed up data access by orders of magnitude. A query against the database can force a scan of columns of one or more tables within the database. If the tables are large, the scan can be very time consuming. The query can be shortened if the columns of the database tables are indexed. Using an index to find data in a given column can be an efficient method of searching. But, an indexed column requires maintenance to be effective. For example, indexes need to be updated whenever data changes occur to keep the indexes accurate. If the data changes, the corresponding index which can refer to that changed data must be updated if the changed data is to be found in a query through the use of an index. If an entry in a row or column is deleted, the index should be updated.
It is clear that some indexes may be used quite frequently while other indexes may not be used via a query very often. Given the mix of frequently used and infrequently used indexes on a database, some concerns arise. The concerns include whether the maintained indexes are being used, if so, are they being used effectively, and are the indexes being used with insight with respect to their storage. If all permutations of indexes were generated with a database table, then the storage requirements for index storage would rise precipitously and maintenance operations would incur unacceptable overhead to data changes. Also, over time, the manner in which a database is used may change. This change may result in a use that neglects the use of some indexes and may indicate a need for greater use of other indexes.
In some instances, queries against a database may present opportunities to generate indexes which do not currently exist in the table. To date, the prior art has not well accommodated characterization of the use of indexes in databases.